Overview

The first release of Pedagogica 2.0 in August 2004 was a rushed alpha version. Over the next few months several important improvements were made, and the next release in April 2005 is 2.0 beta. This document is to help developers convert their activities from 2.0 alpha to 2.0 beta.

Here are the important changes to note:

• The EASL and Script packages were removed. A small subset of the code in Script was moved into the Pedagogica package.
• Pedagogica now uses JavaScript Rhino version 1.5R4.1, a step on the way to using the lates version of Rhino.
• Several classes were moved to other packages. The ones relevant to the conversion will be noted below.

Recommended steps

1. Open the Edit Class Path dialog and remove any jar files that are known not to be used, or even might not be used (they are easy to put back in if they turn out to be necessary). Typical jars that should be removed are:
   1. Script/lib/script.jar
   2. EASL/lib/easl.jar
   3. Domain/lib/domain.jar (this will be replaced by Loader/lib/loader.jar)
   4. thirdparty/js.jar (this will be superceded by a jar file with a version)
2. While still in the Edit Class Path dialog remove from imports any classes that conflict with JavaScript such as Boolean, Integer or String. Also remove org.concord.pedagogica.ui.CCXMLText from imported classes and replace it with org.concord.view.XMLText (from frameworkview.jar). Occurences in the script of CCXMLText should be replaced by XMLText.
3. Probably most imports from org.concord.domain should be replaced with their counterparts in org.concord.loader (loader.jar).
4. Make necessary view conversions and handler conversions (see below).

Right click to get the menu:

And select Edit CLass View to get this:

View Conversions

In addition to replacing references to refactored classes in scripts and imports, their occurence in views must also be addressed. The two classes that appear most frequently in alpha to beta conversions are org.concord.pedagogica.ui.CCDomainButton and org.concord.pedagogica.ui.CCXMLText.

1. Open the Edit Class Path dialog and remove any jar files that are known not to be used, or even might not be used (they are easy to put back in if they turn out to be necessary). Typical jars that should be removed are:
   1. Script/lib/script.jar
   2. EASL/lib/easl.jar
   3. Domain/lib/domain.jar (this will be replaced by Loader/lib/loader.jar)
   4. thirdparty/js.jar (this will be superceded by a jar file with a version)
2. While still in the Edit Class Path dialog remove from imports any classes that conflict with JavaScript such as Boolean, Integer or String. Also remove org.concord.pedagogica.ui.CCXMLText from imported classes and replace it with org.concord.view.XMLText (from frameworkview.jar). Occurences in the script of CCXMLText should be replaced by XMLText.
3. Probably most imports from org.concord.domain should be replaced with their counterparts in org.concord.loader (loader.jar).
4. Make necessary view conversions and handler conversions.

To do a class view conversion, open the Edit View window on the root and create a new placement and open the Show Properties dialog on it. Then, one by one, select likely conversion candidates out of the component list in the properties dialog, clicking the Set Component button to examine the class of that component. If the class needs to be changed, use the Select Class item on the pulldown next to the class property. The resulting dialog should let you browse to the appropriate class and select it. Use javax.swing.JButton to replace org.concord.pedagogica.ui.CCDomainButton and org.concord.view.XMLText to replace org.concord.pedagogica.ui.CCXMLText.

Get menu:

Open Edit View and right-click for it's pop-up menu:

Create a new Placement:

Change the class of a component:

Select the new class:

Handler Conversion

The old style of event hander was implemented in Rhino (JavaScript) as follows:

function handler()
{
    function someMethodOne(event)
    {
       // handler method code here
    }

    function someMethodTwo(event)
    {
      // handler method code here
    }
}
var listener = new SomeListener(handler);

Because the latest versions of Rhino no longer support the above form, we must now implement the handlers like this:

var handler =
{
    someMethodOne: function(event)
    {
       // handler method code here
    }, // note this comma - necessary when there is more than one method

    someMethodTwo: function(event)
    {
      // handler method code here
    }
}; // note this semicolon - ends object value initializer
var listener = new SomeListener(handler);

All of the alpha version activities' handlers must be manually converted to the latter form. This is currently the most labor-intensive part of the conversion task. If I can make the time to do so, adding regex search and replace to ACE could greatly simplify this.

By convention in most activities, the actual listener object is instantiated immediately after the handler definition. Thus, you can find most handlers by searching for the script instantiation of the interface, e.g. search for new ActionListener( to find most button handlers.

classView.jpg (image/jpeg)
editClassPathSelect.jpg (image/jpeg)
editViewSelect.jpg (image/jpeg)
newPlacementSelect.jpg (image/jpeg)
placementAndProperties.jpg (image/jpeg)
changeComponentClass.jpg (image/jpeg)
changeComponentClassSelect.jpg (image/jpeg)